feat(agc): import uniform multisampled DCC fast clears - #5939

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Merged onto current main d92a8da (no textual conflict), this head 347d11b93 no longer compiles on Linux (GCC 13.3, Release):

core/libs/prx/libSceAgcDriver/Graphics/src/MultisampleTarget.cpp:396:10: error: too few arguments to function 'void AgcDriver::Graphics::{anonymous}::guard(const Context&, const ColorTarget&, const std::shared_ptr<std::atomic<bool>>&, const std::shared_ptr<std::atomic<bool>>&)'

The three-argument call at line 396 came in on main with 03e6cbf ("pass the created target's active flag to guard after the merge with main"), after this PR's base 8f51d3b; this PR gives guard the extra metadataValid parameter.

Two titles stop on main d92a8da at the check this PR targets, AGC graphics: DCC over a multisampled color target is unsupported (Linux, RTX 4070 Ti, NVIDIA 595.99):

• Rush 2 Recompiled (PPSA69423, catalog release): 1 s after start-up (reported on AGC: normal rendering to an 8x MSAA DCC color target is refused (PPSA99902) #5336).
• Metal Gear Solid 4 (PPSA18194, 01.004.003): the Master Collection launcher's Online Manual, 2 of 2 runs, as it loads its bookassets_* bundles.

I can run both on a rebased head.

AI-assisted: yes

@milescoviello Fixed and rebased in 3851b712c: createFilled now passes the target's metadataValid flag to guard.

I reproduced the compiler error before that correction. The updated head passes the full Windows build and selected NVIDIA/AMD tests; Ubuntu24.04/GCC13.3 builds all four fixture executables and passes the five supported lavapipe groups once plus five repeats. The description has exact pins, hardware limits and the2x/8x software-device skips.

Could you retest Rush2 and the MGS4 manual at this head? I have not independently run those titles. AI-assisted: Codex.

Thanks for the quick fix. 3851b712c merged onto main a08de68 builds on Linux (GCC 13.3, Release). Same setup as before (RTX 4070 Ti, NVIDIA 595.99, pad input):

So both titles get past the check on main and then reach this PR's own unimplemented paths: CMASK compression or a register clear in both, and in Rush 2 also a write to a resident multisampled DCC target. Happy to rerun them on a later head.

AI-assisted: yes

@milescoviello Thanks for the scalar measurements. They distinguish two states that the combined refusal message did not.

I checked Mesa's pinned CMASK definitions: the zero MSAA CMASK code denotes a register color clear plus FMASK clear, and is marked illegal with DCC. I am retaining the Rush 2 refusal rather than admitting that combination solely because both snapshots are uniform. This does not prove the title submitted invalid metadata; an earlier missing operation or ordering discrepancy could still produce the observed state.

For MGS4, cmaskFastClear=0 alone does not establish that CMASK is unused: CMASK also describes FMASK compression. At this PR's head, DecodeColorBuffer populates the CMASK range for multisampling when CB_COLOR_INFO.COMPRESSION (bit 14) is set, independently of FAST_CLEAR (bit 13). Mixed bytes therefore do not, by themselves, establish uninitialised memory or justify ignoring the range. Whether uniform numeric DCC clears make that mapping irrelevant still needs source or hardware evidence.

If your captured scalar state includes the complete CB_COLOR_INFO value, FMASK-address-present boolean and FMASK swizzle, those would help distinguish the remaining mode without sharing raw addresses. No capability change is selected from the combined error or uniformity alone. AI-assisted: Codex.

They didn't, so I captured them. This is a throwaway print at the top of MultisampledDccClear, before the CMASK check, on 3851b712c merged onto main f633042 (Linux, RTX 4070 Ti). Two runs per title, and the values repeat:

• Rush 2 is refused on a uniform 0x00 CMASK with fast clear enabled, with a uniform 0x00 DCC. The call before it, on the same target, has 0xcc / 0x40 and passes.
• The MGS4 manual's target has cmaskFastClear 0, and its CMASK is mixed, with a first byte that changes between runs. That reads like CMASK memory nothing initialised (inferred). Its DCC is a uniform 0x00.

AI-assisted: yes

A correction and the values you asked for. In my last comment I wrote that Rush 2's accepted call and its refused call are on the same target. That's wrong. They are two different targets, with their own CMASK and DCC. Wave Race 64 Recompiled (PPSA69424, 00.001.000), new in the catalog, behaves the same: on main 5d9dcc4 it stops at 1 s on DCC over a multisampled color target is unsupported, and with 3851b712c merged onto 5d9dcc4 it stops at 2 s on the CMASK refusal.

Registers. These come from a throwaway print in DecodeColorBuffer that logs each distinct multisampled DCC state. Both titles print one state, used by all three of their multisampled targets:

Where the zeros come from. APS5_TRACE_DISPATCH_IO=2 shows each target being cleared the same way in both titles, with one compute shader that takes an address, a size and a 32-bit pattern in its user data. The dispatches are decoded on a different thread from the draw's import:

1. CMASK 0xdddddddd
2. FMASK 0x02020202
3. DCC 0x00000000
4. CMASK 0xcccccccc
5. DCC 0x40404040

For the refused target all five dispatches are logged before the draw thread's import. The import still reads 0x00 in both CMASK and DCC, so none of them had landed yet. Recorder::PendingWriteOverlaps reports nothing for those ranges, I think because the shader is address-based and its writes reach guest memory at the batch's write-back. After a full recorder->Sync() the same read returns 0x40.

With a sync at the top of the import, ahead of the generation collect:

         if (use.cmaskAddress != 0) dccRanges.push_back({use.cmaskAddress, use.cmaskBytes, 0});
+        if (auto* recorder = Recorder::Active(); recorder != nullptr) {
+            Recorder::CountSync(1);
+            recorder->Sync();
+        }
         for (auto& range : dccRanges) {

all three targets import with CMASK 0xcc and DCC 0x40, in both titles. Both then stop at 2 s on writes to a resident multisampled DCC target or its metadata are not implemented. They run the same five fills again on a target that is already resident, which your checkDccCurrent refuses. So with the read ordered, neither title reaches the zero CMASK / DCC state on these targets. I haven't checked whether a full sync is the right granularity, or how the MGS4 manual's mixed CMASK was produced.

Linux (Ubuntu 24.04, GCC 13.3, Release), RTX 4070 Ti, NVIDIA 595.99. Two runs of each title per build, same results.

AI-assisted: yes

A follow-up on the ordering, plus an offer.

The clear dispatches in Rush 2 and Wave Race 64 run the same 11-word compute kernel, and so do Ruffle's (PPSA68091) CMASK/FMASK/DCC clears. Its user data is 0, 0, address low, address high, last offset, pattern. Each of the 64 threads of a group stores the 16-byte pattern with global_store_dwordx4 at address + min(16 * thread, last offset):

d7460000 04010c06 7e080205 7e0a0205 7e0c0205 7e0e0205 34000084 26000004 dc788000 00020400 bf810000

Because the stores are address-based, the recorder notes no pending write for them, so a CPU-side read of that memory doesn't wait for them. I matched the kernel into fillBuffer as one more DwordPatternFill, next to MatchConstantDwordFill. With that on 3851b712c + main 5d9dcc4, and without the sync I suggested above, both titles import all three targets as 0xcc / 0x40 and stop at 2 s on writes to a resident multisampled DCC target or its metadata are not implemented, the same as with the sync.

On main alone the same match changes Ruffle. Its target's CMASK seed now sees the pending 0xcc fill, and Ruffle stops at 11 s on the CMASK 0x4004600000 of a multisampled color target reads as mixed, which is not modeled. On main 5d9dcc4 it runs (0 of 6 runs today stopped) because the seed read normally lands before the fill and sees zeros. Older main builds stopped there in 2 of my 6 sweep runs, presumably when the fill won the race. So the HLE needs the 0xcc CMASK state modeled first, and your branch does that for DCC targets.

I haven't opened it as a PR because of that. Would you rather I open it after #5939 lands, or carry it in here? The match and its test (AddressPatternFill.cpp: the matcher's cases, and the fill followed by a CP DMA copy of the range through the submit path) are on a local branch. I can push it to my fork if you want to look.

Linux, RTX 4070 Ti, NVIDIA 595.99.

AI-assisted: yes

@milescoviello The range diagnostic is now proposed upstream in #6869, explicitly depending on #5939. Its own two-file change (+30/-3) is pushed on codex/fix-msaa-dcc-range-diagnostic-main896. The composition includes main 896e1b2b7 and exact parent 3851b712c; the parent PR's head stays unchanged. After the parent lands, the follow-up can be reduced to its own commit.

The existing refusal prefixes and predicates remain. Details identify the color/DCC/CMASK plane, address, byte count and sample count; they do not identify the writer or implement resident writes.

Fresh application/library (relinker, libs) builds pass on Windows 11/GCC 15.2r7 and Ubuntu 24.04 WSL2/GCC 13.3. Linux selected targets build; DCC state and llvmpipe 4x clear each pass 3/3 (six processes, max 0.40 s), with actual runtime device identity verified and no selected omissions/skips/timeouts. Software 2x/8x are unavailable and excluded. Conventions and registration pass.

The complete source tree differs from the tested/analyzed fa1161690 only in Linux executable runtime linkage and CI configuration, so unchanged Windows GPU and static-analysis evidence is retained at that pin below. The Linux checks were repeated because the linkage change can affect exception handling. This is not a new full-suite, title-run, writer-attribution or resident-publication claim. If you retest the parent on Rush 2/Wave Race with the diagnostic, please retain the full refusal text. AI-assisted: Codex.

Thanks @Amoenus, and thanks for the credit. The dispatch part of my branch turned out to be the same change as #6543 (karanvora2599: RADV's fill-memory kernel as a buffer fill), which was already open when I found it. So I'd rather not open a second PR for it, and #6543 is the follow-up I'd point review at.

I ran it with this PR on main 5d9dcc4 instead, 60 s with scripted pad input, two runs each:

With #6543, both titles reach the resident-write stop every time. That fits the fills being ordered before the import, as with the full sync I tried earlier. Without it, which stop you get depends on that race. On Ruffle (PPSA68091), #6543 makes the race go the other way: it then stops on the CMASK ... reads as mixed, which #6669 handles (numbers there). #6669 doesn't change these two titles. #5939 and #6543 merge cleanly. #6669 conflicts with #5939 on the CMASK seed line, and keeping both conditions resolves it.

AI-assisted: yes

Checked on Linux (GCC, merged onto current main): agc_driver_msaa_dcc_state, agc_driver_msaa_dcc_clear_{2,4,8} and the existing alpha-to-coverage tests pass; with MultisampleTarget.cpp/State.cpp reverted to main the four new tests fail. Unsupported DCC/CMASK states throw and the TechnicalDebt entry matches the code. Merging once the full Build is green.

@adriadam10 The previously observed Linux fixture blocker is now resolved on main. Main 66e290f1c includes #6889, whose sole patch is identical to #6789's already validated storage correction.

On plain main66, Ubuntu24.04 WSL2 / GCC13.3 / Release, the real CPU graphics target builds and agc_driver_graphics passes3/3 fresh processes (maximum3.29s); the journal control passes1/1 (0.02s). The two unavailable heap-mirror checks per graphics process remain excluded. #6792 is being closed for this observed failure. No GPU, title or DCC runtime claim follows from these CPU/mock checks.

This removes the specific failure seen in the earlier seven-PR Build below. A fresh maintainer-triggered combined Build for #5939 on updated main is still needed before calling the PR's full CI green. The separate main66 Build does not include #5939. This report does not replace either CI result; no upstream merge or workflow dispatch was performed.

Latest plain-main CI: main93 Build38941524429 has successful Windows and Linux jobs. The Windows log reports zero failures among1321 CTest results, including agc_shader_helpers (0.04s) and agc_driver_pm4_ring_invalid (0.03s). Skipped tests are excluded from coverage. In particular, Windows configures only three real AGC execution fixtures and compiles ExecutionTestNotBuilt.cpp for the others; this is not a full AGC execution-fixture build/run. This plain-main result excludes #5939. A fresh maintainer-triggered combined Build remains needed; it must disclose the selected fixtures. The single passing main run does not resolve #6791's intermittent hang.

Earlier main66 CI follow-up: the Linux job passes. The completed Windows job also passes agc_driver_graphics (7.89s), then has one separate failure among1321 results: agc_driver_pm4_ring_invalid prints its success message but times out at30.01s. This matching post-success timeout is reported on existing #6791; its lock/root cause is unconfirmed. This is plain-main CI, not a combined #5939 result.

AI-assisted: Codex; fresh CPU checks run locally.

Re-checked on Linux (GCC, merged onto current main): agc_driver_msaa_dcc_state, agc_driver_msaa_dcc_clear_{2,4,8}, agc_driver_graphics and the alpha-to-coverage tests pass; without the change the new tests do not build. Unsupported DCC/CMASK states throw and the TechnicalDebt entry matches the code. Merging once the full Build is green.

Rebased onto current main (conflict with #5881 in MultisampleTarget.cpp: the target initialisation now uses recordToGeneral from main and clears with the PR's initial DCC value). Built and ran the libSceAgcDriver tests on the rebased tree: agc_driver_msaa_dcc_state, agc_driver_msaa_dcc_clear_{2,4,8}, agc_driver_graphics and the alpha-to-coverage tests pass; the only failure is agc_driver_tessellation (segfault), which also fails on unrelated PRs. Merging once the full Build is green.